home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 531 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  6.1 KB
  1. Subject: Re: Blocks
  2. Date: Fri, 24 Jun 1994 13:01:44 +0200 (MDT)
  3. In-Reply-To: <Pine.3.87.9406231534.A12383-0100000@grad> from "Timothy Miller" at Jun 23, 94 03:58:34 pm
  4. From: Annius.Groenink@cwi.nl (Annius Groenink)
  5. X-Face: "E3Hm]k]&:,OEP<{D2ixJf>-9[qOGLebNa0&cQyFL-a~)kTM3&&I"gFw=fJ]K%1IduGjOE`
  6.  ZGu]&~G]QNGa7i/L!+#Xng<|+}HKYHj~5?fTInUEUh0$I1gBI7jrA!&_|e/pR1[cX:^xgJTPsrjA_9
  7.  m8Zli[|.-u{]+c1(6C7mL*m`/_J\>.{4!:g
  8. Mime-Version: 1.0
  9. Precedence: bulk
  10.  
  11.  
  12. The David Letterman of the Gem-list,  Tim Miller:
  13.  
  14.  
  15. > Obviously, you've not tried to implement this system before... either 
  16. > that or you made it more complicated than it really is.  In reality, the 
  17.  
  18. I know how easy the block=cursor system is to implement.  That's why it
  19. is extra suspicious from user-friendliness perspective.  It is simply a
  20. hack promoted to a feature.  An excuse of the lazy programmer.
  21.  
  22.  
  23. > metaphor is nothing more than just a 'way' of looking at it.  It turns 
  24. > out to take less to implement, because you don't have all the EXTRA CODE 
  25. > required implement an INDEPENDANT block-handling system.  In the 
  26. > big-cursor system, the block-handling and normal insertion code are the 
  27. > SAME code, performing the same tasks, although you could do it 
  28. > differently, but that would probably make it more difficult than the 
  29. > other method.  And on top of that, it requires the user to LEARN a LOT 
  30. > LESS.  And besides that, the user is no less likely to make mistakes 
  31. > using your system than the big-cursor system.
  32.  
  33. Well...  except for ^A...  And as to your SHIFT+BACKSPACE problem,  the
  34. reason that most block=cursor programs use UNDO to undo just the LAST
  35. CHARACTER inserted is because of the same programmer laziness.  YES,
  36. orthogonal,  NO good.
  37.  
  38.  
  39. > Too much thinking for the programmer?  People developing and explaining 
  40. > theories tend to over-explain things for the sake of giving multiple ways 
  41. > of understanding the same thing.  And we implement this system because we 
  42. > DO care about what the user wants and IS WELL ACCUSTOMED TO!
  43.  
  44. Many people stick to WordPerfect for decades because that's what they're
  45. WELL ACCUSTOMED TO.   Is that a good reason?
  46.  
  47.  
  48. > Too much thinking for the programmer?  Are you one of the proponents of 
  49. > that short-cut config file?  Sheesh.
  50.  
  51. I'm actually implementing bits of it.
  52.  
  53.  
  54. > You're right.  It's too much.  I prefer the terms "Hide Block", or 
  55.  
  56. Clear Selection. (=deselect all)
  57.  
  58. > "Deselect Block".  Using the word 'all' in there doesn't seem to make 
  59. > much sense.
  60.  
  61. I agree.
  62.  
  63. > )Hm.  If the Mac system were really  as orthogonal as people on the  list
  64. > )claim, hitting  backspace should  remove the  block PLUS  the  character
  65. > )right before the block;  for that's what is does when the block is  size
  66. > )0 (the cursor).  Similar for Delete.
  67. > 
  68. > Now, don't get silly on us.  If you have a real arguement against it, 
  69. > fine, but don't give us useless comments.
  70.  
  71. You simply say they're useless because you don't understand me.  What
  72. I'm saying does make sense,  but perhaps not to a lazy reader.
  73.  
  74.  
  75. > And per your comment about dangerous applications... some dangers are 
  76. > very difficult to 'implement out'.  It's best, most often, to change 
  77. > something else, easier to change.
  78.  
  79. OK,  you go for the easy way,  fine.  But don't let your laziness
  80. influence our proposal.  Designing a good GUI and going for the most
  81. easy implementation simply don't go together at all.
  82.  
  83. >    close window =
  84. >       if (changed)
  85. >       {  switch (ask_user)
  86. >          {  case Cancel
  87. >          :     do noting
  88. >          ;  case Abandon
  89. >          :     close
  90. >          ;  case Reload
  91. >          :     reload
  92. >          ;  case Save
  93. >          :     save,  close
  94. >          ;  case Save As...
  95. >          :     save as, close
  96. >    ;  }  }
  97. >       else
  98.  
  99. > Talk about ugly code.  I'm sorry, but this is a mess.  You're violating 
  100. > numerous rules of readable code.  Is that why you said not to cover this 
  101. > subject?  And those semicolons and colons all lined up there are ugly, 
  102. > distracting, and out of place.
  103.  
  104. Because you're not ACCUSTOMED TO my way of formatting C.  It is actually
  105. *very orthogonal*,  and gives precise information about the block
  106. structure just because of the alignment of the semicolons.
  107.  
  108. > How about go for something a little more normal?
  109. > 
  110. >     if (changed) {  
  111. >         switch (ask_user) {
  112. >             case Cancel:
  113. >                 do noting;
  114. > 
  115. >             case Abandon:
  116. >                 close;  
  117. > 
  118. >             case Reload:
  119. >                 reload;
  120. > 
  121. >             case Save:
  122. >                 save,  close;
  123. > 
  124. >             case Save As...:
  125. >                 save as, close;
  126. >         }
  127. >     } else {
  128. >         ........
  129. >     }
  130.  
  131. Because 'normal' is usually not the best one can think of.  Most
  132. progammers *are* lazy.  Your code goes even more heavily against
  133. 'rules for readability'  that mine.  Finding matching semicolons and
  134. brackets is really hard when they're not aligned.
  135.  
  136.  
  137. > There.  That's better.  Now that I can read it, I can ask you why you are 
  138. > closing upon save.  Why?  That's the most annoying feature of First 
  139. > Word.  Don't close on save.  If I want to close, I'll TELL it to close.
  140.  
  141. Oh PLEASE.  We're discussing the DIALOG that pops up AFTER the user has
  142. selected CLOSE.  Obviously all actions except CANCEL should result in
  143. the window to be closed.  Talking about a lazy reader...
  144.  
  145.  
  146. > We need to make a standard that is robust, applicable to a wide range of 
  147. > applications, and bullet-proof.  We can do it, but it'll take a lot of 
  148. > work.  We've accomplished just about everything already.
  149.  
  150. OK,  let's introduce a special logo
  151.  
  152.     <ASCII 249> PROOF
  153.  
  154. for applications that have 'redraw screen' on Control A.  There won't
  155. be many,  though,  I guess.
  156.  
  157.  
  158. > Ha!  Do you think Atari's going to be around that long?  They don't 
  159. > develop computers any more.  We're just trying to salvage what's left of 
  160. > the developers and make our twilight years the best they can be.
  161.  
  162. Hm.  The truth can be embarassing.
  163.  
  164. -- 
  165. Annius V. Groenink | E-mail: avg@cwi.nl      | Private & ZFC: (e-mail soon)
  166. CWI, Kruislaan 413 | Room:   M233            | P.O. Box 12079
  167. 1098 SJ Amsterdam  | Ext:    4077            | NL 1100 AB Amsterdam 
  168. Netherland         | Phone:  +31 20 592 4077 | Phone: +31 20 695 9901
  169.